The present invention relates generally to motion controllers and simulation systems including motion controllers.
Motion controllers are components that range from ON/OFF devices with simple linear controllers to complex, user programmable modules that act as controllers within complex integrated multi-axis motion systems. For example, a motion controller can be used in flight simulator systems. Typically, a simulation computer supplies position, velocity, and acceleration (PVA) demands for three (3) or more axes of motion to the controller on a precise periodic schedule, for example, one PVA demand set per axis each millisecond. As such, the simulation computer supplies a piece-wise motion trajectory over time that the motion controller ensures the physical axis follows the supplied motion trajectory.
In addition to sending axis trajectories to the controller, the simulation computer can also read measurements, or readouts, from the motion controller of the actual physical axis PVA. The simulation computer can then use this data to modify its subsequent PVA demand set(s). This control mode represents a form of testing known as hardware-in-the-loop (HWIL) testing, wherein a larger control-loop is formed around the seeker and the flight motion simulator, of which the motion controller is an essential component.
Currently available motion controllers are typically based upon industrially packaged personal computer (PC) hardware. In most such designs the PC processor, hereinafter referred to as the “PC”, performs in a supervisory and communications role only, while digital servo loop closure and other axis-specific, hard real-time functions are executed on a daughter or slave card processor optimized for mathematical operations. The daughter or slave card is often a digital signal processor (DSP).
The daughter card(s), hereinafter referred to as the “DSP card(s)”, execute the control algorithms for one or more axes and normally exist as slaves on a communication bus mastered by the PC. In most cases this bus is an industry-standard parallel input/output (I/O) bus such as ISA bus or a Peripheral Component Interconnect (PCI) bus.
As illustrated in FIG. 1, in a number of currently available HWIL control systems 10, PC 30 supervises the start-up, shut-down, and run-time operations of motion controller 20 while also generally maintaining the demand and readout PVA data transactions for all simulator axes by moving data between one or more DSP cards 40 and a reflective memory interface (RMI) 50. Typically, RMI 50 of motion controller 20 is, like DSP card(s) 40, yet another slave card on I/O bus 60 of PC 30. RMI card 50 of motion controller 20 is in communicative connection with a corresponding RMI card 70 residing within a simulation computer 80 via, for example, an ultra high-speed communications link such as a fiber optic link 90. This arrangement yields extremely low data communication latencies between reflected (that is, identical content maintained) memory on RMI card 50 and RMI card 70. This low latency is important in minimizing the phase margin of, and thereby enhancing the stability of, HWIL control system 10.
In its function as the I/O bus master of motion controller 20, PC 30 must: (i) Quickly recognize, whether by polling or via an interrupt from the RMI card 50, that a new block of multi-axis demand PVA data is available in the memory of simulator RMI card 70; (ii) Read (whether by programmed I/O into PC memory or via direct memory access (DMA)) the block of demand PVA data and then write (distribute) the demand PVA data to the appropriate DSP card(s) 40; (iii) Read (whether by programmed I/O into PC memory or via direct memory access (DMA)) the readout PVA data from DSP card(s) 40 and then write the resulting block of multi-axis readout PVA data to the memory of RMI card 50; and (iv) Set a flag variable in the memory of RMI card 50 to signal simulation computer 60 that the demand block/readout block transaction is complete.
The above-described motion controller architecture and HWIL operational scenario, which is the basis of, for example, a number of existing commercial and historical flight simulation controllers, is predicated on the ability of PC 30 to respond with very low latency to the arrival of the demand PVA data block and then rapidly move demand and readout data among multiple DSP cards 40 and simulator RMI card 70.
The requirement of bounded (guaranteed) timeliness on PC 30 forces the modern motion controller designer to utilize a real time operating system (RTOS) executing on PC 30. A number of such RTOS's are commercially available. A real-time operating system or RTOS schedules tasks to be performed according to a set of established priorities. Such tasks typically follow a predictable schedule of execution. The ability to respond to environmental inputs in a priority-based manner allows a real-time operating system to respond almost instantaneously to events as they occur and, in general, an RTOS is capable of guaranteeing a certain capability within a specified time constraint Unfortunately, most RTOS's are substantially more expensive and more difficult to operate than a general purpose operating system (GPOS) such as Microsoft Windows®. Moreover, RTOS's generally lack the features that computer-savvy users have come to expect when using a motion controller's local display, for example, a GPOS graphical user interface (GUI) and file system (as, for example, provided with Microsoft Windows®). The RTOS thus adds both recurring and non-recurring design costs to motion controller 20 and further disadvantages the design either by forcing compromises in the controller's local user interface, or by adding the additional cost to provide a second dedicated local interface PC 100 that communicates with controller PC 30.
It thus remains desirable develop improved motion controllers and simulation systems that reduce or eliminate the above and other problems with currently available motion controllers and simulation systems.